feat: Add __repr__ generation support for @c_class dataclasses #411
Conversation
Summary of ChangesHello @Dayuxiaoshui, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for automatic __repr__ generation for @c_class dataclasses, which is a great step towards feature parity with standard Python dataclasses. The implementation is clean, adding repr parameters to the @c_class decorator and field() function to control the behavior. The dynamic generation of the __repr__ method is well-handled. I've included a couple of suggestions in python/tvm_ffi/dataclasses/_utils.py to improve code maintainability by reducing duplication and to enhance code style for better readability.
|
@tqchen cc |
|
Please add some unittests |
|
@junrushao I am ready, please review it again. |
junrushao
left a comment
junrushao
left a comment
There was a problem hiding this comment.
Thanks for the contribution! I love those changes. Have you tested the nested case, where a c_class may contain other c_classes?
| func.__qualname__ = f"{cls.__qualname__}.{name}" | ||
| func.__doc__ = f"Method `{name}` of class `{cls.__qualname__}`" | ||
| attrs[name] = func | ||
| setattr(cls, name, func) |
There was a problem hiding this comment.
curious why we removed this line?
There was a problem hiding this comment.
The setattr(cls, name, func) line was removed because methods are already added to the attrs dictionary (line 67) and the new class is created via type(cls.name, cls_bases, attrs) (line 76), which automatically includes all attributes from attrs. Setting methods on cls (the input template class) is unnecessary since cls is not the final class being created - the final class gets all methods from attrs when created by type().
There was a problem hiding this comment.
We haven't explicitly tested nested c_class cases yet. The current repr implementation uses {self.{field_name}!r} which calls repr() on each field value, so nested c_class objects should automatically use their own repr methods. I can add a test case to verify this behavior works correctly with nested structures.
2 participants
reprparameter toc_class()decorator (default: True)reprparameter tofield()function (default: True)method_repr()to generate repr methodsThis implements part of #356 dataclass feature parity.